Reviewed and validated on the merge ref. node --check passes on all four changed JS files (audio.js, ui/menus.js, app.js, version.js). No automated web test infrastructure exists in the repo, so verification beyond syntax is limited to what you already did on a live iPhone. The claude-review CI failure here is infrastructure (OIDC token expiry on the action), not a code issue.

Most of this is solid work — the [hidden] !important fix is correct and well-commented, the pointer-event handling is careful (single-pointer tracking, 12px drag cancel, 750ms click-suppression window), the Web Audio buffer cache with LRU eviction is a real improvement over per-effect Audio() elements, and the stale-effect drop after 1.5s is a sensible game-feel choice. But there is one regression worth discussing before merge.

Desktop screen-reader/Tab order regression

The previous commit on these files (714fbf4 Mobile web client polish, same author) explicitly stated:

"CSS order flips History above Game on narrow viewports without changing DOM order, so Tab and screen-reader sequence stay desktop-correct (Game → History → Chat)."

That commit used order: 1/2 to flip visually on mobile while keeping DOM order Game → History on desktop. This PR reverses that decision: it physically moves the History <section> above Game in index.html, then uses grid-template-areas to position Game back on the left visually.

Net effect:

• Desktop visual layout: unchanged (as the PR description claims).
• Desktop tab / screen-reader / browse-mode reading order: changed from Game → History → Chat to History → Game → Chat.

For this project — CLAUDE.md says "minimize tab stops — every extra control is navigation overhead for screen reader users" — that means every state change a blind desktop player now lands in the History log before the interactive Game menu. The PR description says "desktop layout preserved" but doesn't acknowledge the DOM/SR-order change.

The clean fix

Keep the original DOM order (Game, History, Chat) and use grid-template-areas for both layouts — that's what the PR already does for desktop, just extend the same technique to mobile. Pure CSS change, no DOM reordering needed. The visual goal (History on top mobile, Game on left desktop) is achievable without affecting reading order.

If you really want History first in the DOM

Focus management can soften the initial-arrival case but doesn't substitute for DOM order:

<section id="game-panel" class="panel game-panel" tabindex="-1">…</section>

gameShell.hidden = false;
document.getElementById("game-panel").focus();

This makes the screen reader announce "Game, heading level 2…" right when the shell appears, instead of starting at History. You could do the same on server state changes that return the turn to the user — focus the actions list so the new menu is announced immediately.

The limit: browse mode (NVDA, JAWS) and VoiceOver's virtual cursor walk DOM order, not focus. So when the user presses H for next heading, arrows through the page, or uses the heading rotor, they still hit History first. Focus management fixes the moment after login and after turn changes; it doesn't fix exploratory reading.

Auto-focusing on every server update is worse — it interrupts the user mid-sentence if they were reading the history log when their turn started.

So focus management is worth layering on regardless (the initial-arrival announcement is genuinely helpful), but for fixing the regression specifically, the DOM-order fix is one-line cheaper and has no edge cases.

Smaller notes (non-blocking)

Redundant preload list. The setTimeout(() => preloadEffects([…12 sounds]), 0) block at engine construction duplicates a literal subset of DEFAULT_PRELOAD_EFFECTS that unlock() also preloads. The dedup in queueEffectPreload prevents double-fetching so it's not buggy, but the two literal copies will drift. Either extract a CRITICAL_PRELOAD_EFFECTS constant or drop the setTimeout entirely — unlock runs on first user gesture, which is the earliest a buffered effect can actually play anyway.

cache: "force-cache" on fetch — relies on the version bump (2026.05.07.1) for invalidation. Sounds rarely change, so this is the right tradeoff.

Muting handles both paths. Element-based effects use effect.muted = muted; buffered effects set gain.gain.value = muted ? 0 : volume. Both correct. Buffered effects keep playing silently rather than stopping, which is fine for short SFX.

Happy to chat through the layout option you prefer.